Hardly anything is more frustrating in IVR usage than encountering a design in which callers can enter a loop -- making a series of choices in which they unintentionally wind up back at a dialog step they've already gone through.
One way to detect loops is to step through the detailed design while creating detailed use cases (also known as scenarios-of-use), as opposed to reviewing a large design page by page. If fortunate enough to have a tool that automatically generates test cases, designers should also perform a review of the test cases to uncover any undesirable experiences such as looping.
Another best practice to follow is to keep counters of how many times a caller is prompted for certain things (like an account number) and put a cap on the tries. Once the maximum number is hit, either provide an alternate method for information-gathering, disconnect the call, or allow an agent transfer. If a caller wasn't able to provide a valid account number the first 3 times the IVR asks, chances are by the 10th time, she still won't be able to.
One way to detect loops is to step through the detailed design while creating detailed use cases (also known as scenarios-of-use), as opposed to reviewing a large design page by page. If fortunate enough to have a tool that automatically generates test cases, designers should also perform a review of the test cases to uncover any undesirable experiences such as looping.
Another best practice to follow is to keep counters of how many times a caller is prompted for certain things (like an account number) and put a cap on the tries. Once the maximum number is hit, either provide an alternate method for information-gathering, disconnect the call, or allow an agent transfer. If a caller wasn't able to provide a valid account number the first 3 times the IVR asks, chances are by the 10th time, she still won't be able to.